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DETAILED ACTION 

1 . This action is responsive to communications: Request for Continued 
Examination, filed 26 December 2006, to the Original Application, filed 9 December 
2003. 

2. The objection to the abstract has been withdrawn as necessitated by 
amendment. 

3. The objection to the drawings has been withdrawn as necessitated by 
amendment. 

4. The objection to the specification has been withdrawn as necessitated by 
amendment. 

5. The objection to Claims 3, 4, 14, 15, 21 , and 22 has been withdrawn as 
necessitated by amendment. 

6. The rejection of claims 1 and 7-10 under 35 U.S.C. 102(b) as being clearly 
anticipated by Ayers, I., "AbiWord's Potential," Linux Gazette, Issue 43, July 1999, last 
downloaded by the Examiner on December 20, 2005, from: 
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www.linuxgazette.com/issue43/ayers.html, downloaded pages 1-4, [hereinafter "Ayers"], 
has been withdrawn as necessitated by amendment and newly found prior art. 

7. The rejection of claims 2-6, and 1 1-23 under 35 U.S.C. 103(a) as being 
unpatentable over Ayers, I., "AbiWord's Potential," Linux Gazette, Issue 43, July 1999, 
last downloaded by the Examiner on December 20, 2005, from: 
www.linuxgazette.com/issue43/ayers.html, [hereinafter "Ayers"], in view of W3C, "XML 
Schema Part 0: Primer, W3C Recommendation, 2 May 2001 ," last downloaded by the 
Examiner on December 19, 2005, from: www.w3.org/TR/201/REC-xmlschema-0- 
20010502, downloaded pages 1-67, [hereinafter "XML Schema"], and W3C, "XML 
Schema Requirements, W3C Note 15 February 1999," last downloaded by the 
Examiner on December 19, 2005, from: www.w3.org/TR/NOTE-xml-schema-req, . 
downloaded pages 1-5, [hereinafter "XML Requirements"], has been withdrawn as 
necessitated by amendment and newly found prior art. 



8. Claims 1-23 are pending. Claims 1,11, and 19 are independent claims. 
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Claims Rejection - 35 U.S.C. 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

9. Claims 1 and 6-10 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Ayers, "AbiWord's Potential", hereinafter "Ayers", in view of Rohr, "RE: Styles 
Again", hereinafter "Rohr". 

As per independent claim 1 and dependent claim 6, Ayers teaches 
A method for representing field structures in a markup language 

document, comprising: 

inputting an application document that has been generated by an 

application that uses a file format that is specific to the application. 
Specifically, the specification discloses that the invention "provides a method to 
represent an application's native field structures in markup language (ML) such as 
XML." See, Disclosure, page 6, lines 12-13. Ayers teaches: "The most significant 
difference between AbiWord and nearly every other word processor available is the 
nature of the native file format. An *.abw file is written in XML and thus is also in ASCII 
format; the files can be read by any text editor." See, Ayers, page 2, fourth paragraph. 
Therefore, Ayers teaches the limitation of "a document that has been generated by an 
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application that uses a file format that is specific to the application," and more 
specifically, teaches a native file format in a markup language, specifically XML. 

Ayers also teaches 

determining properties corresponding to a field that relates to at least one 

section of an application document; 
It is noted that the term "properties" is not specifically defined in the specification. The 
disclosure associates the term in a general sense with simple and complex fields, as in 
the following: "the properties of the complex field (when the field is a complex field) are 
mapped into elements, attributes, and values of the ML file." Disclosure, page 18, lines 
9-10. "Attributes" are also noted as one of the properties elsewhere in the disclosure. 
See, disclosure, page 3, line 26. The disclosure also defines that an element may have 
no attribute associated with it. See, disclosure, page 3, lines 27-28. Further evidence 
that the term refers to the general appearance of the document is taken from the 
disclosure, stating: "the fields and the properties associated with the fields may change 
from page to page, section to section, chapter to chapter and the like." Disclosure, 
page 18, lines 22-23. Based on the above analysis, it is believed that the applicants 
intended the term "properties" to be used in the general sense of the appearance of the 
text, and such definition will be used for the remainder of this Office Action. In support 
of the above definition of "properties" as known to one of ordinary skill in the art at the 
time of the invention, see, Harold, Elliotte Rusty, "XML Bible," IDG Books Worldwide, 
1999, pages 369-388. 

Ayers also teaches 
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mapping the properties of the field into at least one of a markup language 

element, an attribute, and a value; and 
See, Ayers, page 3, last two full paragraphs and citing code example from the 
screenshot and showing font and line properties and values. Note that Ayers teaches 
that the code is the markup language mapped from the properties of the document field 
displayed in the screenshot. 

Ayers also teaches 

storing the properties of the field in the markup language document 

whereby applications different from the application can understand the mapped 

list properties stored in the markup language document. 
(See, Ayers, page 3, last two full paragraphs and citing code example from the 
screenshot. Note that Ayers teaches saving the document shown in the screenshot, 
which creates the saved code that is saved in memory. 

Ayers also teaches: 

Where the file format is in a format that is native to the application 

Specifically, Ayers teaches that "The most significant difference between 
AbiWord and nearly every other word processor available is the nature of the native file 
format. An *.abw file is written in XML and thus is also in ASCII format; the files can be 
read by any text editor." See, Ayers, page 2, fourth paragraph, emphasis added.) 

Ayers does not teach expressly that the file format includes unique properties for 
describing fields within the document, where the unique properties are defined by the 
application. 
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Rohr teaches including unique properties for describing fields within a document, 
such as character properties and paragraph properties. Rohr further teaches that the 
unique properties relate to at least one section of the application document, such as a 
paragraph within the application document (See Rohr, entire document). 

Ayers and Rohr are analogous art because they are from the same field of 
endeavor of creating and manipulating electronic documents. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to include the definition of character and paragraph properties of Rohr with the 
functionality of Ayers. The motivation for doing so would have been to set the 
properties of the various components of the document, such as affecting the color of the 
text within a paragraph of the document (See Rohr, Page 1, italicized text at mid-page). 
Therefore, it would have been obvious to combine Rohr with Ayers for the benefit of 
setting the properties of the various components of the document, such as affecting the 
color of the text within a paragraph of the document, to obtain the invention as specified 
in claims 1 and 6. 

As per dependent claim 7, Ayers and Rohr teach the limitations of claim 1 as 
described above. Ayers also teaches: 

The method of Claim 1, further comprising: 

determining properties corresponding to an additional field that relates to 
at least one section of the application document; 

mapping the properties of the additional field into at least one of a markup 
language element, an attribute, and a value; and 
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storing the properties of the additional field in the markup language 
document. 

It is noted that this claim is read as the method including to edit and add or insert text to 
a document and then to convert to XML and save the resulting combined document. 

(See, Ayers, page 3, last two lines, teaching the editing, or modification, of an 
XML document in AbiWord.) 

As per dependent claim 8, Ayers and Rohr teach the limitations of claim 1 as 
described above. Claim 8 incorporates substantially similar subject matter as claimed in 
claim 1, and in further view of the following, is rejected along the same rationale. 

It is noted that claim 1 specifies storing "the field," which is a singular "field." 
See, claim 1, lines, 5 and 9. There may be many fields in a document. Claim 8 further 
limits claim 1 by specifying a repetition of the field storage process until "all fields" have 
been stored. Claim 8 merely specifies completing the field storage process, which is 
the equivalent of storing the document. 

Ayers teaches the storage of the document which teaches the storage of all 
fields in the document. See, Ayers, page 3, last two full paragraphs and citing code 
example from the screenshot. Note that Ayers teaches saving the document shown in 
the screenshot, which creates the saved code that is saved in memory. 

As per dependent claim 9, Ayers and Rohr teach the limitations of claim 1 as 
described above. Ayers also teaches: 
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The method of Claim 1, wherein the properties of the fields stored in the 
markup language document are understood by an application that understands 
the markup language when the field is not native to the application. 
Specifically, See, Ayers, page 2, third full paragraph, teaching that an AbiWord 
document is saved in an *.abw file written in XML and that the files can be read by any 
text editor. IN addition, Ayers teaches fields stored in XML that are understood by an 
application that understands the markup language when the field is not native to the 
application. See, Ayers, page 2, fourth paragraph teaching, as follows: "AbiWord can 
also save in the HTML and RTF formats, both of which are accessible with word 
processors such as MS-Word and WordPerfect." Therefore, AbiWord's fields in XML 
are understood by markup languages not native to AbiWord, such as HTML. 

As per dependent claim 10, Ayers and Rohr teach the limitations of 
claim 1 as described above. Ayers also teaches: 

The method of Claim 1, wherein the markup language document is 
manipulated on a server to substantially reproduce the field of the application 
document notwithstanding the presence of an application that generated the 
markup language document. 
Specifically, See, Ayers, page 2, third full paragraph, teaching that an AbiWord 
document is saved in an *.abw file written in XML and that the files can be read by any 
text editor. See also, Ayers, page 3, bottom two lines, teaching that the document save 
in AbiWord may be modified by hand in an editor rather than a word processor. It is 
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inherent from the ability to be read by any text editor and be modified by hand that the 
document may be manipulated on any suitable computing device, including a server. 



10. Claims 2-4, 11-15, and 17-23 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Ayers, "AbiWord's Potential", hereinafter "Ayers", in view of Rohr, 
"RE: Styles Again", hereinafter "Rohr", and further in view of W3C, "XML Schema Part 
0: Primer, W3C Recommendation, 2 May 2001, hereinafter "XML Schema" and W3C, 
"XML Schema Requirements, hereinafter "XML Requirements". 

As per independent claim 11, Ayers teaches: 

A computer-readable medium for representing fields in a markup language 

document, comprising: 

inputting an application document that has been generated by an 

application that uses a file format that is specific to the application; 
(The specification discloses that the invention "provides a method to represent an 
application's native field structures in markup language (ML) such as XML." See, 
Disclosure, page 6, lines 12-13. Ayers teaches: "The most significant difference 
between AbiWord and nearly every other word processor available is the nature of the 
native file format. An *.abw file is written in XML and thus is also in ASCII format; the 
files can be read by any text editor." See, Ayers, page 2, fourth paragraph. Therefore, 
Ayers teaches the limitation of "a document that has been generated by an application 
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that uses a file format that is specific to the application," and more specifically, teaches 
a native file format in a markup language, specifically XML.) 

Ayers also teaches: 

determining properties relating to one or more fields used within the 

application document. 
It is noted that the term "properties" is not specifically defined in the specification. The 
disclosure associates the term in a general sense with simple and complex fields, as in 
the following: "the properties of the complex field (when the field is a complex field) are 
mapped into elements, attributes, and values of the ML file." Disclosure, page 18, lines 
9-10. "Attributes" are also noted as one of the properties elsewhere in the disclosure. 
See, disclosure, page 3, line 26. Further evidence that the term refers to the general 
appearance of the document is taken from the disclosure, stating: "the fields and the 
properties associated with the fields may change from page to page, section to section, 
chapter to chapter and the like." Disclosure, page 18, lines 22-23. Based on the above 
analysis, it is believed that the applicants intended the.term "properties" to be used in 
the general sense of the appearance of the text, and such definition will be used for the 
remainder of this Office Action. In support of the above definition of "properties" as 
known to one of ordinary skill in the art at the time of the invention, see, Harold, Elliotte 
Rusty, "XML Bible," IDG Books Worldwide, 1999, pages 369-388. 

Ayers also teaches: 

determining whether the field is one of a complex field and a simple field; 
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Specifically, See, Ayers, page 3, screenshot and the last two full paragraphs, wherein 
the screenshot teaches both simple and complex fields, with simple and complex 
elements, and the code example teaches that the simple field is mapped and stored. 
Ayers teaches the screenshot with the text to be saved, and Ayers teaches code 
generated in XML from saving the text in AbiWord. 

Ayers does not expressly teach to determine whether the field is one of a 
complex field and a simple field. 

XML Schema teaches that simple and complex data elements are defined as 
part of the XML language. See, XML Schema, downloaded page 7. 

Ayers and XML Schema are analogous art because they are from the same field 
of endeavor of creating and manipulating electronic documents. At the time the 
invention was made, it would have been obvious to one of ordinary skill in the art to 
differentiate between a simple element and a complex element, and to use such 
differentiation to determine how to render a word document. It is at least obvious, and 
possibly inherent, from the screenshot and the code example shown in Ayers that 
AbiWord determines whether the data is complex or simple. 

The suggestion or motivation for combining the teachings of Ayers, that a word 
processor program could convert and store documents in XML, with the teaching of 
XML Schema, including that document types are distinguished as simple or complex, is 
expressly stated in XML Requirements, stating: "The following usage scenarios 
describe XML applications that should benefit from XML schemas. * * * 4. Traditional 
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document authoring/editing governed by schema constraints." See, XML 
Requirements, page 3. 

The combination of the teachings of Ayers to convert and store word processing 
documents in XML combined with the teachings of XML Schema that data may be one 
of two types, simple or complex, would be an invention whereby a document mapped to 
XML would also distinguish and map simple and complex elements, and that such could 
be stored in memory.) 

Ayers also teaches: 

writing the properties into at least one of a markup language element, ah 

attribute, and a value; and 
Specifically, See, Ayers, page 3, last two full paragraphs and citing code example from 
the screenshot and showing font and line properties and values. Note that Ayers 
teaches that the code is the markup language mapped from the properties of the 
document field displayed in the screenshot. 

Ayers also teaches: 

storing the properties in the markup language document such that the 

fields of the application document are substantially maintained when the markup 

language document is parsed by an application that is different from the 

application used to generate the application document. 
Specifically, See, Ayers, page 3, last two full paragraphs and citing code example from 
the screenshot. Note that Ayers teaches saving the document shown in the screenshot, 
which creates the saved code that is saved in memory. 
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Ayers also teaches: 

Where the file format is in a format that is native to the application. 

Specifically, Ayers teaches: "The most significant difference between AbiWord 
and nearly every other word processor available is the nature of the native file format. 
An *.abw file is written in XML and thus is also in ASCII format; the files can be read 
by any text editor." See, Ayers, page 2, fourth paragraph, emphasis added.) 

Ayers, XML Schema and XML Requirements do not teach expressly that the file 
format includes unique properties for describing fields within the document, where the 
unique properties are defined by the application. 

Rohr teaches including unique properties for describing fields within a document, 
such as character properties and paragraph properties. Rohr further teaches that the 
unique properties relate to at least one section of the application document, such as a 
paragraph within the application document (See Rohr, entire document). 

Ayers, XML Schema, XML Requirements, and Rohr are analogous art because 
they are from the same field of endeavor of creating and manipulating electronic 
documents. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to include the definition of character and paragraph properties of Rohr with the 
functionality of Ayers, XML Schema and XML Requirements. The motivation for doing 
so would have been to set the properties of the various components of the document, 
such as affecting the color of the text within a paragraph of the document (See Rohr, 
Page 1, italicized text at mid-page). Therefore, it would have been obvious to combine 
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Rohr with Ayers, XML Schema and XML Requirements for the benefit of setting the 
properties of the various components of the document, such as affecting the color of the 
text within a paragraph of the document, to obtain the invention as specified in claim 11. 

As per dependent claim 2, Ayers and Rohr teach the limitations of claim 1 
above, also teaches: 

further comprising determining whether the field is one of a complex field 

or a simple field. 

Specifically, See, Ayers, page 3, screenshot and the last two full paragraphs, wherein 
the screenshot teaches both simple and complex fields, with simple and complex 
elements, and the code example teaches that the simple field is mapped and stored. 
Ayers teaches the screenshot with the text to be saved, and Ayers teaches code 
generated in XML from saving the text in AbiWord. 

Ayers and Rohr do not expressly teach to determine whether the field is one of a 
complex field and a simple field. 

XML Schema teaches that simple and complex data elements are defined as 
part of the XML language. See, XML Schema, downloaded page 7. 

Ayers, Rohr, and XML Schema are analogous art because they are from the 
same field of endeavor of creating and manipulating electronic documents. At the time 
the invention was made, it would have been obvious to one of ordinary skill in the art to 
differentiate between a simple element and a complex element, and to use such 
differentiation to determine how to render a word document. It is at least obvious, and 
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possibly inherent, from the screenshot and the code example shown in Ayers that 
AbiWord determines whether the data is complex or simple. 

The suggestion or motivation for combining the teachings of Ayers, that a word 
processor program could convert and store documents in XML, with the teaching of 
XML Schema, including that document types are distinguished as simple or complex, is 
expressly stated in XML Requirements, stating: "The following usage scenarios 
describe XML applications that should benefit from XML schemas. * * * 4. Traditional 
document authoring/editing governed by schema constraints." See, XML 
Requirements, page 3. 

The combination of the teachings of Ayers to convert and store word processing 
documents in XML combined with the teachings of XML Schema that data may be one 
of two types, simple or complex, would be an invention whereby a document mapped to 
XML would also distinguish and map simple and complex elements, and that such could 
be stored in memory. 

As per dependent claim 3, Ayers and Rohr in view of XML Schema and further 
in view of XML Requirements teaches: 

The method of Claim 2, wherein an instruction portion of the field 

comprises at least one of richly formatted text and embedded additional fields 

when the field is a complex field. 
The rejection of claim 2 is incorporated herein by this reference. See also, Ayers, page 
2, third full paragraph, teaching that AbiWord can be saved in RTF format. 
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As per dependent claim 4, Ayers and Rohr in view of XML Schema and further 
in view of XML Requirements teaches: 

The method of Claim 2, wherein an instruction portion of the field excludes 
richly formatted text and embedded additional fields when the field is a simple 
field. 

The rejection of claim 2 is incorporated herein by this reference. 

It is noted that the term "richly formatted text" is not defined in the application. It 
is believed that applicants intended to refer to Microsoft Corporation's Rich Text Format 
(RTF) standard, and this definition will be used for the remainder of this Office Action. 

It is inherent in the XML schema that simple types cannot have element content 
and cannot carry attributes, and it is therefore inherent in AbiWord, as taught by Ayers 
to save documents in XML. See in support of this inherent property, XML Schema, 
downloaded page 7. 

As per dependent claim 12, claim 12 incorporates substantially similar subject 
matter as claimed in claim 9, and is rejected along the same rationale. 

As per dependent claim 13, claim 13 incorporates substantially similar subject 
matter as claimed in claim 10, and is rejected along the same rationale. 

As per dependent claim 14, claim 14 incorporates substantially similar subject 
matter as claimed in claim 3, and is rejected along the same rationale. 

As per dependent claim 15, claim 15 incorporates substantially similar subject 
matter as claimed in claim 4, and is rejected along the same rationale. 
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As per dependent claim 17, Ayers and Rohr in view of XML Schema and 
further in view of XML Requirements teaches: 

The method of Claim 1 1, further comprising representing the field with at 

least one of a fldChar element and instrText element when the field is determined 

to be a complex field. 
The rejection of claim 1 1 is incorporated herein by this reference. 

It is noted that the ability to create an element type is inherent in the XML 
language and is therefore inherent in AbiWord, which is taught by Ayers to save 
documents in XML. 

As per dependent claim 18, claim 18 incorporates substantially similar subject 
matter as claimed in claim 7, and is rejected along the same rationale. 

As per independent claim 19, Ayers and Rohr in view of XML Schema and 
further in view of XML Requirements teaches: 

A system for representing fields in a markup language document, 
comprising: 

an application that is configured to: 

input an application document that has been generated by an 
application that uses a file format that is specific to the application; 

determine properties relating to a field included in at least one 
section of an application document; 

determine whether the field is one of a complex field and a simple 

field; 
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map the properties into at least one of a markup language 
element, an attribute, and a value; and 

store the properties in the markup language document; and 
a validation engine configured to validate the markup language document. 
It is noted that claim 19 incorporates substantially similar subject matter as claimed in 
claim 1 1 , and in further view of the following, is rejected along the same rationale. 

Validation of an XML document is expressly taught in XML Schema, which 
states: "An instance document may be processed against a schema to verify whether 
the rules specified in the schema are honored in the instance. Typically, such 
processing actually does two things, (1) it checks for conformance to the rules, a 
process called schema validation . . .." See, XML Schema, downloaded page 59. See 
also, XML Schema, downloaded page 60, expressly teaching validation of simple and 

l 

complex element types. It would have been obvious to one of ordinary skill in the art at 
the time of the invention to validate an instance document in order to confirm that it 
follows the rules of the schema. 

The specification discloses that the invention "provides a method to represent an 
application's native field structures in markup language (ML) such as XML." See, 
Disclosure, page 6, lines 12-13. Ayers teaches: "The most significant difference 
between AbiWord and nearly every other word processor available is the nature of the 
native file format. An *.abw file is written in XML and thus is also in ASCII format; the 
files can be read by any text editor." See, Ayers, page 2, fourth paragraph. Therefore, 
Ayers teaches the limitation of "a document that has been generated by an application 
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that uses a file format that is specific to the application," and more specifically, teaches 
a native file format in a markup language, specifically XML. 

As per dependent claim 20, claim 20 incorporates substantially similar subject 
matter as claimed in claim 9, and is rejected along the same rationale. 

As per dependent claim 21, claim 21 incorporates substantially similar subject 
matter as claimed in claim 3, and is rejected along the same rationale. 

As per dependent claim 22, claim 22 incorporates substantially similar subject 
matter as claimed in claim 4, and is rejected along the same rationale. 

As per dependent claim 23, claim 23 incorporates substantially similar subject 
matter as claimed in claim 10, and is rejected along the same rationale. 



11. It is noted that any citations to specific, pages, columns, lines, or figures in the 
prior art references and any interpretation of the references should not be considered to 
be limiting in any way. A reference is relevant for all it contains and may be relied upon 
for all that it would have reasonably suggested to one having ordinary skill in the art. 
See, MPEP 2123. 
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Allowable Subject Matter 

12. Claims 5 and 16 objected to as being dependent upon a rejected base claim, but 
would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 



Response to Arguments 

1 3. Applicant's arguments with respect to claims 1 -23 have been considered but are 
moot in view of the new ground(s) of rejection. 



Conclusion 

14. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Laurie Ries whose telephone number is 571-272-4095 
The examiner can normally be reached on M-F, 6:00am-3:30pm. If attempts to reach 
the examiner by telephone are unsuccessful, the examiner's supervisor, Heather 
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Herndon can be reached on 571-272-4136. The fax phone number for the organization 
where this application or proceeding is assigned is 571-273-8300. 
1 5. . Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

LR 



Heather R. Herndon 
Supervisory Patent Examiner 
Technology Center 2100 



